Topics on this page include:
There are five different types of supported calendar events in Lotus Notes up through the Version 7 codestream. In Lotus Notes 8, a sixth type is added.
Meetings involve more than one party, and this is the major difference between this type of event and the next four. The owner of the meeting, usually the chair of the meeting, is the only person allowed to make changes to a meeting. Changes include general information updates, rescheduling, adding users, and other actions.
Invitees can only accept, decline, delegate, or counter propose the request. Meetings are the most complicated of the calendaring events and, because of the dialog between invitees and the chair person, meeting events are workflow events.
Appointments are like meetings, except that there is no participant to send to or receive notices from. An example is a doctor appointment.
A calendar entry used as a reminder.
Designed to be used to mark an anniversary. This event is used for holidays and other anniversaries that repeat at regular intervals.
Used for events that last all day, such as a day away from work, or a seminar.
New in Lotus Notes 8. The event announcement is similar to a broadcast meeting in earlier releases, except that it does not expand groups, so it’s now possible to send a single invitation to an extremely large number of people. It is used when the chair does not want responses, such as when a large group of people are invited to a teleconference. The event announcement workflow is the same as Meeting, with certain response options disabled.
Back to top
The Notes calendar contains a variety of views, each of which can be configured to the user’s preferences. Calendar events appear in the calendar views if they contain the fields CalendarDateTime (for placement in the view) and usually StartDateTime and EndDateTime, to calculate duration of the entry. Some entries like Reminders have a duration of zero and do not have EndDateTime but are still valid in the Calendar view. Items that do not contain these fields appear in the list-type views, called All Documents, Meetings, or All Calendar Entries.
Two major types of calendar items not usually showing in the calendar views are Responses, which use the form “Notice”, and parent documents of repeating meetings or appointments. These do not show in the Calendar view because they do not have the CalendarDateTime item. Notices can display in the Calendar view if ghosting (an optional new feature in Lotus Notes 8) is enabled. This feature allows incoming unprocessed meeting notices (like invites and reschedules) to appear on the calendar, so they can also have CalendarDateTime and will appear in Calendar views.
If Calendar documents are malformed or corrupted, they may not appear correctly in Calendar views. Use the list-type views to determine if documents are missing from a Calendar view.
Simple & Repeating Events
Simple events are events that do not repeat. They can have invitees or not, but the key is that they occur only once. These events are stored as a single note in the Notes calendaring system. The note contains a CalendarDateTime item set to the date and time where it should appear in the Calendar view. Usually this is the same value as for the item StartDateTime. If the note does not contain the CalendarDateTime item, it will appear only in the All Documents, Meetings, or All Calendar Entries views. The ApptUNID value is used to uniquely identify an event.
Repeating events are scheduled more than once over time and are represented by at least two notes in a parent-child relationship. The parent note is identified by its ApptUNID item (which is its note universal ID), and the child note is identified by the same ApptUNID as the parent and the original RepeatInstanceDates. The ApptUNID and RepeatInstanceDates items form a key pair of values that uniquely identify a particular repeat instance. More details are covered in the Repeat Model section of this paper.
Back to top
Every user, room or resource that can be involved in C&S workflow needs to have a calendar in some database somewhere. There is always a ‘home’database and there may be replicas of it on other servers. Each user, room and resource can have different calendar related settings such as available hours, available days, default settings, and more.
Settings are stored on a Notes profile doc whose name is Calendar. All calendar profiles have one feature in common, the $BusyName item. This item is used to indicate the name of the entity the calendar profile is for.
While there are some common settings for all entities, there are some settings that are specific to the type of entity. For example, R&R entities may have a list of who is allowed to reserve them without 3rd
party approval and C&S entities would have default entry durations and alarm settings which are not relevant to R&R entities.
Only one user owns a mail database and has their calendar in it, there is no need to specify the optional name on the Calendar Profile. There should only be one Calendar Profile in a users mail file and there must not be any secondary key specified. The owners name is found in the $BusyName item.
Rooms & Resources
There can be any number of rooms or resources in a single R&R database so each room or resources Calendar Profile requires the use of the secondary key value. The value of the secondary key is the canonical name of rhe room or resource. There should be no Calendar Profile in an R&R database without a secondary key specified. The name of the room or resource is found in the $BusyName item.
party code should use the Lotus Notes Profile doc API calls rather than trying to hand craft a Calendar Profile docs totally from scratch. This will minimize the potential risk for creating them incorrectly.
Back to top
Rooms & Resources
The R&R system in versions prior to Lotus Notes 7 consisted of having R&R related work shared or spread between the Router, the R&R Template and the Schedule Manager with any direct communiation and synchronization between any of them. This loose interconnected design was not very robust and could cause user frustration when booking rooms oe resources.
The R&R system was totally redesigned in Lotus Notes 7. The new design was to centralize the final request processing in a new Domino Server task, the Rooms and Resource Manager (RnRMgr). All request processing and busytime update logic was removed from all other places and put into the Rooms and Resource Manager task. This centralization of the request processing not only precludes double booking of R&R, it also allows R&R to be installed in a clustered configuration leading to even availability of the R&R system.
All R&R bookings are done through the use of standard C&S workflow messages no matter the source of the request. 3rd
party applications are no longer able to just create an “Accepted” reservation and have the room booked in busytime. They must create the proper C&S workflow messages and put them into the R&R database for RnRMgr to pick up and process.
Similarly, to change an existing R&R reservation, a standard C&S “Reschedule” notice needs to be created in the R&R database. Any attempt to circumvent the RnRMgr and create ‘booked’ reservations can only result in double bookings because RnRMgr will not update busytime unless it processes the request itself.
The new R&R design does not require an upgraded Lotus Notes client to work. This allows for customers to upgrade the R&R server to get the benefits of the new R& design without also needing update their Lotus Notes Clients. There are some new R&R related features in the Lotus Notes 7 client but they are not required.
When upgrading from pre-Lotus Domino 7.0 to 7.0 or later, there are two essential steps that need to be performed. First, replace the design of any R&R database with the most recenty R&R template. Second, set the Administration Server of the R&R dB to the be the R&R and enable the 4 sysetm Agents in the R&R database.
Some functionality is provided by 4 Agents that are in the R&R template. They are shtipped disabled by default so sites must
enable them with using an ID that is allowed to run Agents on the R&R server every time they replace the design. Failure to do so will result in old documents not being purged out, rooms with future booking limits not being bookable as expected and other such unusual behavior.
Response documents sent by Invitees, Delegees, and/or Resources are an integral part of the C&S workflow. These notices are used to track attendance and report on the status of each attendee, and they must remain in the mail file for these functions to work. These notices do not usually contain a CalendarDateTime field, so they do not appear in the Calendar views, only in the list views and mail views. If these documents are deleted from the chair’s calendar, the invitees will show as No Response.
In meetings, attendees can be invited in three ways: Required, Optional, and FYI. Upon receiving the invitation notice, Required and Optional attendees can accept, decline, counter, or delegate the request. FYI attendees, on the other hand, can only add the event to their calendar or request new information about it. Only the chair is aware of FYI attendees; the other participants do not see FYI attendees.
Back to top